1. Field of the Invention
This invention is related to multimedia packet networks. Specifically, this invention relates to a mechanism to allow such a packet network to more effectively carry telephony messages, and to more efficiently interface with the public switched telephone network (PSTN).
2. Description of the Problem Solved
Evolution of the PSTN has accelerated in recent years; however, most of the PSTN still operates on circuit switched, time division multiplexed (TDM) connections. Integrated services digital network (ISDN) bearer channels often provide transport. In parallel with the PSTN, a packet based data network has evolved. This data network has largely been used for Internet traffic and data networking. Although these networks have been mostly separate until recently, the two networks are starting to merge. The merger of these networks requires that voice traffic be carried over packet networks, and further that such packet networks be able to seamlessly integrate with traditional circuit switched networks, as the two types of networks may carry different call legs of the same call.
FIG. 1 illustrates a typical TDM, PSTN call. Caller 101 places a call to callee 105. The call goes through end office A, 102, over some type of trunk bearer channel to toll office 103, then to end office B, 104, and finally to the callee. Such calls may pass through multiple toll offices, or may be connected directly from one end office to another. In any case, a path of circuits for the call is maintained throughout the call. Signaling between offices is typically provided by an ISUP (ISDN user part) connection. ISUP signaling is well understood and is standard in the telecommunications industry. For more information on ISUP signaling, see the various International Telecommunications Union (ITU) Recommendations pertaining to telephone signaling, including Q.761, Q.764 and Q.931, the most recent versions of which at the time of filing this application am incorporated herein by reference.
FIG. 2 illustrates a call which is similar to the TDM call of FIG. 1; however, in this case, the call is transported from one end office to another (called switch offices, 202 and 204, in this case) via a packet switched network 203. This fact is, in theory, transparent to caller 201 and callee 205. ISUP+ or SIP+ provides signaling in this case. ISUP+ is essentially the same as ISUP except that ISUP+ signals contain extra fields for packet or cell based network information. An International Telecommunications Union (ITU) recommendation has been proposed for ISUP+ as of the filing date of this application as ITU Q.BICC. SIP stands for xe2x80x9csession initiation protocolxe2x80x9d and is a well-known standard. SIP and SIP+ are described in document RFC 2543, published by the Internet Engineering Task Force (IETF), March, 1999 which is incorporated herein by reference. SIP and SIP+ provide the same type of signaling for control of calls, but are more oriented towards packet based networks.
The network of FIG. 2 has been conceptualized for some time, and standards groups and conference groups have written extensively about how to make such a network work in everyday use. In order for the call leg which is handled by the packet network to seamlessly connect with the call legs handled by TDM switching offices, media provided by one type of network must be converted into media provided by the other. This conversion is referred to as circuit emulation services (CES) in an ATM network. The device that provides this conversion is called a media gateway (MG). In the network of FIG. 2, a media gateway handles each end of the bearer connection through packet network 203. The media gateway terminates bearer media streams from both the switched circuit TDM network, and the packet network. The media gateway and the network it serves may be capable of processing audio and video (hence the term xe2x80x9cmultimedia packet networkxe2x80x9d). The media gateway is capable of full duplex media translations. It may also provide other features such as conferencing.
Each media gateway is associated with a media gateway controller (MGC). The media gateway is xe2x80x9cdumbxe2x80x9d in that it does not have call processing capabilities. The call processing capabilities for the network reside in the MGC. An MGC provides the signaling for call control and controls the call state of a media gateway. The protocol used by the MGC to control the MG is called the media gateway control protocol (or the xe2x80x9cMegacoxe2x80x9d protocol). Megaco is an application layer protocol which is also described in ITU Recommendation H.248, which shares a common text with the IETF Internet Draft xe2x80x9cMegaco Protocol,xe2x80x9d and which is incorporated herein by reference. The xe2x80x9cMegaco Protocolxe2x80x9d Internet Draft first became an IETF working document in March, 1999. Within the Megaco protocol, session description protocol (SDP) can be used to describe bearer channel terminations, which are being controlled by the MGC""s. SDP is described in document RFC 2327, published by the IETF, April 1998, which is incorporated herein by reference. Throughout the rest of this disclosure we will refer to Megaco as xe2x80x9cMegaco/H.248.xe2x80x9d
Despite the fact that the theoretical workings of a network like that shown in FIG. 2 have been widely explored, such networks have seen relatively little everyday use. The reason is that there are still problems to be overcome before such networks exhibit the same very high quality of service for voice traffic that users of the PSTN have come to expect. One such problem stems from the fact that there is no dedicated physical path for a call through a packet network, and therefore no way to identify a particular media stream to be associated with a particular call.
A packet switched network, used for transport of audio and video media streams, is typically based on asynchronous transfer mode (ATM), frame relay (FR), and Internet protocol (IP) technologies. Public ATM networks generally operate according to the user network interface (UNI). The UNI is described in the book, xe2x80x9cATM User Network Interface (UNI) Specification Version 3.1xe2x80x9d by the ATM Forum, published by Prentice Hall PTR, June, 1995, which is incorporated herein by reference. An update to the UNI version 3.1, xe2x80x9cATM User-Network Interface (UNI) Signaling Specification 4.0xe2x80x9d was published by the ATM Forum in July, 1996, and is incorporated herein by reference. For private ATM networks, the private network to network interface (PNNI) describes the ATM interface. PNNI is covered in the ATM forum document xe2x80x9cPNNI addendum for the network call correlation identifierxe2x80x9d published by the ATM forum in July 1999, which is incorporated herein by reference. In ATM, fixed length cells carry packetized data. Each cell that is sent through the network has a virtual channel identifier, and other addressing information; however, each node in the network handles many cells that are associated with different media streams. Therefore, each call leg on the ATM network may actually go through many different network nodes and many different virtual circuits to complete the network path. It is impossible for an MGC and a media gateway to correlate the call leg throughout its path with a particular call. Since the nodes in the network are unaware of which call""s cells are being sent when, it is difficult to maintain control of the call throughout the network in real time to maintain an appropriate level of quality of service. What is needed is a way within the Megaco/H.248 protocol to absolutely identify a media stream in the network as being associated with a particular call.
The present invention solves the above-described problem by providing an end-to-end call identifier (EECID) for use in an ATM or other type of packet switched network which serves as a transport network for real-time audio and video media streams. The EECID is used to identify a call leg uniquely across the packet network, regardless of the number of nodes used in completing the network path. The EECID allows a call to be identified uniquely within the packet network, so that the media gateway can process the call accordingly.
Either a media gateway or a media gateway controller, at either the originating or terminating end of the call or the packet network can generate the EECID. In describing the invention, we use xe2x80x9coriginatingxe2x80x9d and xe2x80x9cterminatingxe2x80x9d to refer to the calling and called ends of the call path, respectively. We use the terms xe2x80x9cnear-endxe2x80x9d and xe2x80x9cfar-endxe2x80x9d to refer to the end of the path relative to where the particular process being discussed is taking place, usually relative to where the EECID is being created and/or assigned. The terms xe2x80x9cnear-endxe2x80x9d and xe2x80x9cfar-endxe2x80x9d are used independently of the terms xe2x80x9coriginatingxe2x80x9d and xe2x80x9cterminating.xe2x80x9d In connection with call setup, the terms xe2x80x9cforwardxe2x80x9d and xe2x80x9cbackwardxe2x80x9d refer to which end initiates the bearer connection through the packet network. xe2x80x9cForwardxe2x80x9d refers to a process where the originating end sets up the connection, and xe2x80x9cbackwardxe2x80x9d refers to a process where the terminating end sets up the connection.
In one embodiment of the invention, a media gateway creates the EECID, determining its value after receiving a command from its media gateway controller (MGC) that a connection for the call is to be established. The value can be a unique, randomly created number, or the media gateway can use another number that is associated with some part of the call path, such as a call identifier (call-ID), backwards network connection identifier (BNC-ID), or a network call correlation identifier (NCCI). The media gateway sends the EECID to the associated media gateway controller so that it can be forwarded to the far-end media gateway controller and the far-end media gateway. The media gateway then establishes a corresponding bearer connection so that the EECID is associated with the bearer connection and the call, and notifies its MGC that the call has been established. Once the EECID has been created, the steps can be performed in any order.
In another embodiment of the invention, a media gateway controller (MGC) creates the EECID, determining its value after receiving a notification to establish a connection and negotiating connection parameters with a far-end MGC. The notification can either be an offhook notification or a request from the far-end MGC to negotiate connection parameters, depending on whether the near-end MGC is the originating MGC or the terminating MGC. Again, the EECID can be a unique, randomly generated number. The EECID can also be a number associated with some other part of the call path, such as a session identifier (session-ID) or a BNC-ID. Once the EECID has been created and assigned, the near-end MGC sends the EECID to its associated media gateway, and sends the EECID to the far-end MGC so that the EECID is associated with the call and the bearer connection which will be established through the network. Once the EECID has been created, the steps can be performed in any order. Regardless of whether the MG or MGC determines the EECID, once both the near-end and far-end media gateways have the EECID and know which call it is associated with, the EECID can be included in packets which are part of the media stream. For example, if the packet network is an ATM network, the EECID is included in ATM cells that make up the media stream to uniquely identify the call.
The invention is implemented by software in combination with the hardware of the media gateway and media gateway controller. The software which implements many aspects of the present invention can be stored on a media. The media can be magnetic such as diskette, tape or fixed disk, or optical such as a CD-ROM. Additionally, the software can be supplied via a network. A media gateway is essentially a switching system containing switching fabrics, a computing module, network interfaces, and other resources. The network interfaces are implemented by adapters which are connected to switching fabrics to allow access to the system from the networks. Input/output modules or adapters allow software to be loaded and various maintenance functions to be performed. A computing module contains a processor and memory that execute the software and provide the means to control the operation of the media gateway to implement the invention.
The media gateway controller can also be a switching system, but would more typically be a type of workstation containing a bus such a personal computer interconnect (PCI) bus. A workstation that typically implements the invention includes a plurality of input/output devices and adapters for connection to the necessary networks. A system unit includes both hardware (a central processing unit and memory) and software which together provide the means to implement the media gateway controller.
The invention operates in a network in which media gateways act as endpoints to call legs being carried on a bearer channel between networks. Each media gateway is controlled by and connected to a media gateway controller. An MGC uses the previously mentioned Megaco/H.248 protocol to control its media gateway, and the invention provides an extension to the Megaco/H.248 protocol to move the EECID between media gateways and media gateway controllers. It should be noted that the invention can be used in a network in which only one MGC controls multiple media gateways, or in a network in which one media gateway manages both ends of a connection. In the latter case it is still important to be able to identify the call within the media gateway.